home *** CD-ROM | disk | FTP | other *** search
/ Internet E-Mail Workshop / Internet E-Mail Workshop.iso / info / ircrule. < prev    next >
Internet Message Format  |  1993-06-30  |  10KB
  1. From owner-operlist@cs.bu.edu Mon Jul 15 16:33 EDT 1991
  2. Received: from CS.BU.EDU by chaos.cs.brandeis.edu Mon, 15 Jul 91 16:33:09 edt
  3. Received: by cs.bu.edu (5.61+++/SMI-4.0.3)
  4.     id AA03347; Mon, 15 Jul 91 15:21:01 -0400
  5. Return-Path: <jennifer@algol.astro.virginia.edu>
  6. Received: from BU.EDU by cs.bu.edu (5.61+++/SMI-4.0.3)
  7.     id AA03341; Mon, 15 Jul 91 15:20:55 -0400
  8. Received: from uvaarpa.Virginia.EDU by BU.EDU (1.99) Mon, 15 Jul 91 13:39:46 EDT
  9. Received: from algol.astro.Virginia.EDU by uvaarpa.Virginia.EDU id aa26499;
  10.           15 Jul 91 13:39 EDT
  11. Received: by algol.astro.Virginia.EDU (5.61/1.34)
  12.     id AA06657; Mon, 15 Jul 91 13:36:10 -0400
  13. Date: Mon, 15 Jul 91 13:36:10 -0400
  14. From: jennifer@algol.astro.Virginia.EDU (Jennifer Wesp)
  15. Message-Id: <9107151736.AA06657@algol.astro.Virginia.EDU>
  16. To: operlist@cs.bu.edu
  17. Subject: the.PLAN
  18. Status: RO
  19.  
  20. This is the set of rules for the.PLAN as they now stand.  additional
  21. commentary would be appreciated.
  22.  
  23. Rules for Opers in the.PLAN
  24.     -Jennifer Wesp     (July 1991)
  25.  
  26. The "enforcement" of these will continue much as it has been.  Talk
  27. to the oper in question if there is an oper related problem, or mail
  28. the server admin if the trouble is with the server.  (If the oper
  29. ignores you then also go to the server admin) The only "new" idea is
  30. that a stronger emphasis should be placed on the next server up the
  31. line, if the admin of the server that is a problem proves unhelpful.
  32. The last line of recourse is to request of the links to the "bad"
  33. server that the links be cut.
  34.  
  35. 1) No kills.
  36.    *Exceptions:
  37.     Ghosts.
  38.     Evading Ignore.
  39.     "Stealing" chanop.
  40.  
  41. 2) No squits.
  42.    *Exceptions:
  43.     You can squit links to your own server, but if you
  44.     need to squit one you should probably rethink your
  45.     Y: lines.
  46.     You can squit to fix a routing that puts Europe in
  47.     the middle of two groups of US servers. (or Japan,
  48.     or Australia...)
  49.  
  50. 3) No wallops.
  51.    *Exceptions:
  52.     Discussion of impending squits.
  53.     Discussion of impending Q: lines, suspected hacked
  54.     servers, or other things that are prohibitted.
  55.     The majority of the discussion should go to a
  56.     channel, however.
  57.  
  58. 4) No Walls.
  59.    *Exception:
  60.     War has broken out, the Big One hit California, or
  61.     there is a large meteor on it's way.  There should
  62.     be only one wall in such an event.
  63.  
  64. Commentary by Greg Lindahl:
  65.  
  66. 1) KILL is fairly useless these days. With an autoreconnect
  67.    client, for example, it's impossible to keep someone off of
  68.    IRC by killing them repeatedly. You'll piss off all the
  69.    other operators long before you stop the bad guy. Likewise,
  70.    if someone has a hacked server that allows them to steal
  71.    channel op repeatedly, or evades /ignore of user@host
  72.    repeatedly, killing them a bunch won't help. Killing them
  73.    once might send a message, but if they persist, a complaint
  74.    to a server or site administrator will be much more
  75.    effective than other measures.
  76.  
  77. Other sorts of things (i.e. being rude on a channel) should be
  78. dealt with by channel operators. That's what they're for. We
  79. hope to add /disinvite soon.
  80.  
  81. 2) With the new routing plan, SQUIT will not be needed as much.
  82.    An SQUIT of a major link causes a lot of network traffic,
  83.    and inconveniences the users. Properly designed routing
  84.    means that most of the time, routing will look good -- it
  85.    becomes a statistical process, and we're using the connect
  86.    frequencies as weights to bias the process towards the Right
  87.    Answer. So, no squits.
  88.  
  89. 3) There is a wide difference of opinion what wallops are for.
  90.    If you want to hold a conversation with a lot of operators,
  91.    you're probably better off using a channel and issuing a
  92.    single wallops advertising the disucssion. Remember that
  93.    LOTS of silent operators are on-line at any one time and
  94.    many of them won't be interested in what you have to say.
  95.  
  96. 4) Think of WALL as the equivalent of posting to
  97.    news.announce.newgroups -- you don't want to abuse it
  98.    because you don't want everyone to start ignoring all walls.
  99.    Again, there is a difference of opinion about this. But I
  100.    think that the vast majority think that walling birthdays,
  101.    for example, is a bad idea. This doesn't even begin to
  102.    address situations such as IRC users who don't speak english
  103.    getting walls in english, or someone walling happy birthday
  104.    in Swahili, Japanese, Russian, and 19 other languages to
  105.    make sure that everyone can understand it.
  106. ######
  107.  
  108. Rules for servers
  109.     -Jennifer Wesp (Phaedrus)    July, 1991
  110.  
  111. The "enforcement" of these will continue much as it has been.  Talk
  112. to the oper in question if there is an oper related problem, or mail
  113. the server admin if the trouble is with the server.  (If the oper
  114. ignores you then also go to the server admin) The only "new" idea is
  115. that a stronger emphasis should be placed on the next server up the
  116. line, if the admin of the server that is a problem proves unhelpful.
  117. The last line of recourse is to request of the links to the "bad"
  118. server that the links be cut.
  119.  
  120. 1) No server-open servers.
  121.    
  122.    *Consequently it is BAD to give links that are not for
  123.     servers that are in constant use, because then anyone
  124.     can set a server up that has access to that machine and
  125.     connect to you, if the "right" server is not around.
  126.     Also, infrequently used links should be passworded.
  127.  
  128. 2) No "hacked" servers.
  129.  
  130.    *This includes at least:
  131.     Servers that record messages in any way such that
  132.       anyone save the intended recipients can read them.
  133.     Servers that give channel op to anyone other than the
  134.       person who started the channel, or any subsequent
  135.       people that were given channel op by other channel
  136.       ops.
  137.     Servers that generate any false message, ie fake server
  138.       kills, squits, nick changes, etc.
  139.  
  140. 3) All servers must be within one major version of current.
  141.  
  142.    *This assumes (so far with reason) that major version
  143.     changes will cause incompatibility with old servers,
  144.     and that is to be minimised.  Also that administration
  145.     of a given server should be able to upgrade it every
  146.     4-5 months, or it can be considered defunct.
  147.  
  148. 4) No destructive testing of the network.
  149.  
  150.    *This includes at least:
  151.     KillBots that generate repeated kills
  152.     Any change to servers that disrupts traffic flow for
  153.       any server other than the one in question.
  154.     AutoReconnecting Clients without time delays.
  155.     Q-lining without ALL superhubs doing it simultaneously,
  156.       along with a majority of the hubs.
  157.  
  158. 5) No more than one server per site.
  159.  
  160.    *Assuming that one server can provide adequate coverage for
  161.     at least one site.  If this is not so then adding a new
  162.     server or moving the old one can be discussed.  Our first
  163.     priority is serving users, not creating servers just so
  164.     more people can be operators.
  165.  
  166. Commentary by Greg Lindahl:
  167.  
  168. 1) This is a security issue we haven't dealt with much in the
  169.    past; however, someday someone is going to hack a nameserver
  170.    just to use an unused, unpassworded link. An ounce of
  171.    prevention, etc.
  172.  
  173. 2) The major controversey here is whether or not it's "ok" in
  174.    some circumstances to create channel ops when none are
  175.    present.  I think not, for 3 reasons:
  176.  
  177.  A) It's only appropriate when everyone on the channel agrees.
  178.     There are some users who don't like channel operators and
  179.     avoid channels which have channel operators. So it's unfair
  180.     for them to join (or even create) a channel with no channel
  181.     operators, and see the rules changed before their very eyes.
  182.  
  183.  B) It gets abused when it exists. This is an unfortunate
  184.     reality.
  185.  
  186.  C) It's yet another special thing that an operator can do.
  187.     We're trying to make operators have as few special powers
  188.     as possible.
  189.  
  190. 3) We can't move forward unless people keep up. Running an IRC
  191.    server, unfortunately, takes a relatively large committment
  192.    of time. Someday it won't, but for now... for example, the
  193.    implementation of /disinvite that I have in mind won't work
  194.    until everyone upgrades. The ^G bug won't be history until
  195.    everyone patches or upgrades. Mode +n didn't work until
  196.    everyone upgraded. And so on.
  197.  
  198. 4) There is an alternative net for experiments, if you need to
  199.    do so.  The main IRC net should be considered a "production"
  200.    system, mainly here so people can talk to each other.
  201.    Putting in some Q-lines in some places results in a network
  202.    split, which means people can't talk. Bad.
  203.  
  204. 5) Some people claim that everyone has the RIGHT to be an
  205.    operator, because it's a privledge. I think it's the other
  206.    way around: being an operator is a burden, should be used
  207.    for technical reasons, and should be open to individuals who
  208.    have the technical knowledge to use it.
  209.  
  210. Likewise, it's not efficient for there to be one server per
  211. user. IRC has a large amount of overhead to support a server.
  212. Since we can serve people remotely, it's better to have fewer
  213. servers and more users per server.
  214.  
  215. ######
  216.  
  217. Rules for Superhubs
  218.     -Jennifer Wesp    (July 1991)
  219.  
  220. 1) Superhubs work as a group.
  221.    
  222.    This means that all policy decisions must be agreed upon
  223.    by all Superhub admins.  In case of an unresolvable
  224.    problem that requires action the minority should resign
  225.    if it finds it cannot agree with the action to be taken.
  226.    I would assume, however, that this should never be
  227.    required. (Refers to Q: lining, link cutting, adding new
  228.    code, and anything else where inconsistency across a
  229.    high traffic link will cause trouble.)
  230.  
  231. 2) Superhubs are expected to be patched within 24hrs notice
  232.    as required.
  233.  
  234.    This means that multiple people <must> be knowledgable
  235.    enough and available enough to be around pretty much all
  236.    of the time, and d owhat needs to be done.  a suggested
  237.    method for this would be to, if possible, give another
  238.    active admin access to the server code and .conf of your
  239.    server.
  240.  
  241.  
  242. -jennifer
  243.  
  244.